Frequently, there is a need to understand the relationships between various objects in order to assess the effect that a change associated with one object has on other objects within a system. When a change associated with a first object affects a second object, there is a “dependency” between the objects. Specifically, the second object is the to “depend on” the first object.
What it specifically means for an object to “depend on” another object is determined by the “dependency rules” that are established for the objects in question. For example, in the context of a company, one may define a dependency rule that a first person depends on a second person if the first person is managed by the second person. In the context of software deployment, one may define a dependency rule that a first software module depends on a second software module if the first software module has to be installed before the second software module. In the context of a database, one may define a dependency rule that a first database object depends on a second database object if the definition of the first database object refers to the second database object. In the context of a family, one may define a dependency rule that a first family member depends on a second family member if the first family member is a descendant of the second family member. In the context of a patent application, one may define a dependency rule that a first claim depends on a second claim if the first claim refers to the second claim and incorporates all of the limitations of the second claim.
The foregoing examples illustrate simply dependency rules for several contexts. As is evident by the examples, the “objects” that are subject of the dependency rules vary from context to context. In fact, there is virtually no limit to the type of objects for which dependency rules may be defined. Further, there is no limit to the type and complexity of the dependency rules themselves.
When objects are represented within a computer system, the computer system may be programmed to determine the dependencies between the objects based on the appropriate dependency rules. For example, assume that a database contains a table that includes information about all of the employees of a company. Assume that each row of the table corresponds to an employee, and that a particular column of the table is used to indicate the managers of the employees. Finally, assume that the dependency rule established for the company is that a first employee depends on a second employee if the second employee manages the first employee. In this scenario, a program may be written to determine the dependency relationships between the employees based on (1) the dependency rule, (2) the employee associated with each row, and (3) the manager identified in the column of each row.
In the preceding examples, the dependencies existed between same-type objects. However, dependencies may also exist between different types of objects. For example, a software module that processes certain types of records may “depend on” the format of those records. In this example, the format of a record is a different type of object than a software module, yet the software module depends on the format of the record.
In most cases, the dependency rules establish a transitive relationship. Thus, if A depends on B, and B depends on C, then A depends on C. For example, certain objects in a data warehouse may affect other objects in the data warehouse, which in turn may affect yet other objects in the data warehouse. For example, the objects in the data warehouse may be tables containing source data, code for processing the tables containing the source data, and staging tables. A change in the format of the tables containing the source data may require an update to the code that processes the tables containing the source data. Thus, the code depends on the source data tables. In turn, an update to the code that processes the tables containing the source data may affect other objects in the data warehouse, such as staging tables. Thus, the staging tables depend on the code. Because the staging tables depend on the code, and the code depends on the source data tables, the staging tables (indirectly) depend on the source data tables.
In many situations, it is critical to know the dependencies between objects. For example, in looking at a report that was generated by a business intelligence analysis tool, a person may see what appears to be an error in the amount of money charged to a particular client for a service rendered by a particular business. The source of the error may lie in any of the various objects involved in generating the erroneous number. Unfortunately, the list of objects involved in generating that number may be long, and the dependencies between them may be complex. For example, the business intelligence analysis tool may access a database comprising objects, such as database tables with data describing businesses and their respective clients, as well as transitional objects. The transitional objects may be programs that perform operations on the database tables. Determining whether there is an error entails not only examining the tables that contain the client's data and the table containing the business' data, but may also entail examining the transitional objects between the two tables.
In the foregoing example, the dependency information is important to determine the “lineage” of the erroneous number. A “lineage analysis” involves identifying the set of objects on which an object depends. In other situations, it is important to know which objects depend on a particular object. For example, an “impact analysis” involves identifying which objects will be impacted by a change to a particular object.
Both lineage analysis and impact analysis are painstaking processes if done manually, and require intimate knowledge of the systems and objects involved in the analysis. Tools can be created to help in this analysis. However, the nature of the objects and the dependencies between the objects vary widely. For example, the objects may comprise data describing parties involved in business relationships, people in families, or even geological formations. Further, the nature of the dependencies between these various types of objects vary. Therefore, many different tools would be needed to address all of the types of problems for all of the types of objects and the dependencies between the objects.
As is evident by the foregoing examples, there is a need to provide a scalable, flexible, and expandable way of analyzing the dependencies between various types of objects, from various types of systems, with various types of dependency relationships, without a proliferation of dependency-analysis tools.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.